cncfandomcom-20200223-history
Red Alert File Formats Guide
THE RED ALERT FILE FORMATS GUIDE Release v1.4 Last Updated: 18th April 1997 © 1997 Gavin Pugh (email - rascenedit@geocities.com) (WWW - http://www.geocities.com/TimesSquare/Arcade/5553) The purpose of this guide is to detail the structure of files used in the Game Red Alert, for use to create utilities or editors. Command & Conquer : Red Alert is a trademark and copyright of Westwood Studios, and is so acknowledged. Any trademarks not mentioned here are still acknowledged. If you intend to use quite a bit of this guide in your FAQ or similar text then I would quite like to hear from you, as I can create a reference to it in my guide. Also I want be credited if you use parts of this guide in your own. Any use of information in this guide should credit the relevant author, (me in most cases), in such programs as utilities and editors. If you have a contribution then please email it to the above address, it'll be more than welcome, and of course, you'll be credited for it, any help is appreciated. Web Site Authors : You are welcome (and encouraged) to have my guide on your page(s), as long as you do not modify the HTML file in any way whatsoever, and also I request that you include a link on your site to my site at the address at the bottom of this document. Enough of the legal crap, enjoy.... MIX Files All MIX files I have seen can be used with the old C&C utilites, with the MIX headers following this format, In Red Alert only the more minor MIX files hidden in the CD directories follow the normal MIX format, the others are RMIX files. +--------+------------------------+------+ | HEADER | ARRAY OF OFFSETS/SIZES | BODY | +--------+------------------------+------+ struct MIXheader { WORD NumFiles; //Number Of Files In the MIX LONG DataSize; //Size Of The Body }; The Array of offsets has one entry for each file: struct MIXrec { LONG FileID; //The ID Of The File, derived from the name of the file LONG Offset; //Offset Of The FIle From The Start Of The Body LONG Size; //Size Of The File }; If you know how the ID is calculated, I'd like to hear it, just for completeness. RMIX Files However, the two which don't though are : MAIN.MIX and REDALERT.MIX. These both contain other MIX files which also can't be read by Mixman. I'll refer to these 'special' MIX files as RMIX from now on, as a few others working on MIX files have done. Here is a list of all the RMIX files I have found: MAIN.MIX ;Contains most other MIX files REDALERT.MIX MOVIES1.MIX MOVIES2.MIX GENERAL.MIX SCORES.MIX CONQUER.MIX SPEECH.MIX SOUNDS.MIX RUSSIAN.MIX ALLIES.MIX LOCAL.MIX LORES.MIX HIRES.MIX NCHIRES.MIX EDITOR.MIX EDHI.MIX EDLO.MIX TRANSIT.MIX and SC*.MIX and SS*.MIX, probably used on Counterstrike Well, so far I can amount the structure of an RMIX to: +--------+------+ | HEADER | BODY | +--------+------+ The header is an encoded representation of where and how long each file is in the body section. The body where all the contained files are, stored one after the other, with nothing inbetween. RMIX Header I can almost definately say that the headers include at least: * The offsets of the files, from the start of the body. * The lengths of the files * And some sort of ID, similar to the C&C one. Looking at MAIN.MIX, it is structured like this: +--------+-------------+----------+----------- ... | HEADER | CONQUER.MIX | EDHI.MIX | EDLO.MIX ..... +--------+-------------+----------+----------- ... OFFSETS: 0 EC 213903 220D42 222D68 LENGTHS: EC 213817 D43F 2026 Here is the header in HEX View: 00 00 02 00 6E 3A 77 4B 7A BB E8 57 DB 10 8B 77 EC 67 5C 0C D9 8A 6B 50 47 AC 8D A4 31 FD 0A A1 EB CF F1 5F 93 19 4D FD C6 49 3F 10 67 A5 7B E2 5D 11 98 3C B4 D8 35 40 3B 36 E6 B3 13 37 70 9C 3F 3C E0 70 97 47 1F BC CE 1B B0 D1 68 D4 F3 B7 E2 F6 8A 32 C2 4B 7D BF 43 87 0B 40 63 27 77 9E 9E 94 40 86 9A B6 59 09 15 52 D2 8E FB E6 BA B8 6A 15 FC 31 5A 1C 4A 9E 54 B3 F6 98 66 24 DB 5E 33 14 82 3D 6E 6B 7C 37 EF 3D 58 83 A5 08 D8 2F 9C A0 D0 86 6F C7 65 5F 56 EF E8 7E 13 5F 08 5A 1E E3 E1 E7 47 0E 72 34 4C 65 BD DD 71 AC 83 FD 4C 4C D2 A3 85 E5 06 C3 55 18 BE FA 70 01 81 F1 40 31 5E 71 64 BB 54 04 95 1E 51 10 B6 DF 96 6F 71 C4 6A 19 CE 19 DC 3E 85 1C 4B B1 B3 DC 21 79 D7 B1 65 C1 B8 73 C9 77 A5 14 7B 0C (still in progess, I'm uploading my site now, so I'll be stopping here for the mo) RMT Files (TMP files in Red Alert) Thanks To Moritz Mertinkat, (and Andrew Griffin for the Xdim/Ydim Info) My Note: These RTM files are used in Red Alert for the map tiles, the 3 theater RMIX files contain many of these tiles to put over your maps. These tiles are those you can place using the RA Terrain Editor, but using this method you could also extract the graphics for the INDOOR theater. The header (in pascal): TRMTHeader = record Width : Word; {Width of images, always 24 (18h)} Height : Word; {Heigth of images, always 24 (18h)} NumTil : Word; {Number of Tiles} Unknown1 : Word; XDim : Word; YDim : Word; Size : LongInt; {Size of file} ImgStart : LongInt; {Start of image-data} Unknown3 : LongInt; Unknown4 : LongInt; Index2 : LongInt; Unknown5 : LongInt; Index1 : LongInt; {Offset of "Index"} end; You can use XDim and YDim to determine how the tiles should be used to construct the uber-tile. For example, say XDim = 3 and YDim = 2, then the uber-tile would be a 3x2 tile. This is probably only of use when placing the uber-tile in the first place, as the individual sub-tiles would be placed when the map is being drawn. XDim and YDim give you the dimensions of the uber-tile. If XDim and YDim are both equal to 1, then there is no uber-tile. If this RMT file holds more than 1 tile, then they are all individual tiles and have no special relationship to each other in regards to being parts of a larger tile. Index2-Index1 should be the number of tiles! Index1 is an offset for an array of bytes: Index: ARRAY1..NumTil of Byte; Every entry in this array which points to a specified tile. If the entry is 255 (FFh) then the tile is empty! An example: If you want to display tile 8 of a RMT-file you have to do the following: - open the file - read the header - seek to pos. INDEX1 - read the index - read the 9th byte of it (for tile 8, because the index starts with 0!} - seek to: SizeOf(Header) + Index9 * (24*24) - read 576 byte (24*24) and display them! - close the file All the graphics-data is uncompressed! PCX-files (Documentation by Moritz Mertinkat) My Note: These PCX files are used for 640x400 images in the Windows 95' version of Red Alert, where CPS files are used for the 320x200 ones in DOS. PCX-Header (in pascal): ----------------------- TPCXHeader = RECORD Signature : Byte; Version : Byte; Encoding : Byte; BitsPixel : Byte; XMin : Word; YMin : Word; XMax : Word; YMax : Word; HRes : Word; VRes : Word; Palette16 : ARRAY1..48 of Byte; Reserved : Byte; NumPlanes : Byte; BytesLine : Word; PalType : Word; Dummy : ARRAY1..58 of Byte; end; Description: ------------ Signature: 10 = ZSoft PCX-files Version: 0 = PC Paintbrush v2.5 2 = Version 2.8 with palette information 3 = Version 2.8 without palette information 4 = PC Paintbrush for Windows (Plus for Windows uses Ver 5) 5 = Version 3.0: Used by Paintbrush in Win3.x and Win95, Can be used for 24-bit images!! >>>> NOTE: Version 5 is standard!! PalType: 1 = Color/BW (use this one for 256-color images!) 2 = Grayscale XMin, XMax, YMin and YMax are the image dimensions. HRes and VRes are the horizantal and vertical Resultion of the image in DPI. If you create your own PCX-files, set HRes and VRes to 300. The image data is encoded with RLE (Run Length Encoding) and follows directly after the header. Decoding the PCX-data: ---------------------- First you have to calculate the X- and Y-dimension of the image. X-dimension: Width:= BytesLine*NumPlanes (But I've seen, that there's another way doing this: Width:= XMax-XMin+1) Y-dimension: Height:= YMax-YMin+1 Now, read a single byte (B1) from the PCX-file. If the top two bits of this byte (B1) are set, then the remaining six bits show how many times you have to duplicate the next byte (after B1) in the file. means: If the byte (B1) is > 192, then it is a "Repeat-byte" and you have to duplicate the next byte (after B1) RepeatByte-192 times If the top two bits are not set, the byte (B1) itself is the data with a count of one. means: If the byte B1 < 192 then this byte represents a pixel itself Simply do this with all bytes (and don't forget the linebreaks after Width decoded bytes). If FileSize(PCXFile)-(768+1) = 12 byte before the pal-array, then the following 768 bytes contain the palette information - otherwise there's no palette. (If you have any questions, comments, ect. please email me: Moritz Mertinkat) Some sample-code (in pascal) at: http://home.t-online.de/home/moehrchen (TP Programmers Page) (Download-area, "PCX-viewer 4.0b for 256-color-bitmaps") SHP Files The SHP files are stored in the MIX files. They are used for the units, icons in the sidebar, structures and other graphics. A 6 image SHP would look like: HeaderImgInfo1ImgInfo2....ImgInfo5ImgInfo6ImgInfo7ImgInfo8SHP DATA Note that the two extra Imginfo parts are special, the last one is all nulls, where the offset in the penultimate one points to the end of the file. The header for these SHP files is as follows: struct SHPheader { WORD NumImages; //Number Of Images In SHP file WORD A; //Unknown (please email me if you know what they are) WORD B; //Unknown WORD Width; //Width Of The Images, in pixels WORD Height; //Height Of The Images, in pixels LONG C; //Unknown }; Each Image (and those 2 special bits), are represented by a info part here. struct ImgInfo { 3 BYTES Offset; //Offset of image in file CHAR Format; //Format Of Image (&h80 is Format80, &h40 is Format40, etc..) WORD RefOff; //Offset of reference image for Format20/40 WORD RefForm; //Format of reference image }; Note that the Offset field is different from C&C, with it being 3 bytes, the RefOff field may also be 3 bytes now as well, but the Refform can be a word, so it is most likely not 3 bytes. Packed Sections First, in relation to C&C1 where each cell is represented by 2 bytes, as the total map size in RA seems to be 128x128 then the binary file for the map which could then be fiddled with and read by third-party editors would be a 128x128x3 byte binary file (=48k). Note that 3 bytes per cell in a map section are used in RA. (This would definately be needed if an editor was created allowing the creation of INDOOR maps) To think about.....Maybe putting a 48k SCG01EA.BIN file along with the INI (a'la C&C1), this would be a solution, but unfortunately the RA terrain editor only handles packed maps :( (note that NewINIFormat=1 would be needed for this way to work, and the OVERLAY section used instead of the OverlayPack) This would be a 2-part process: MapPack 1=983704304RREREW84790....... 2=8743907547054......... > Compressed Binary > 48k Map Binary 3=..... 6 8K Chunks In Format80 3 bytes per cell ..... And So On .. < 70 chars a line > Aha! Looked in GAME.DAT for the full alphabet and saw: ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/ (This most probably is the same as Base64, but for completeness, I've decoded it myself) Theory: ------- The GAME.DAT sequence shows that A would be 0, B=1, C=2..... +=62 and /=63 Each character represents 6 bits, arranged as follows 6 bits 000000111111000000111111 So in the compressed Binary form: 8 bits 000000111111000000111111 The '=' character means take off 2 bits from the byte sequence, this means that the whole sequence is MOD 8, so doesn't leave any stray bits behind. Now all the data can be handled in normal hex byte form. This Process In Reverse ----------------------- If you want to get from the byte sequence to the ASCII string again (maybe for a map tile placing utility), use this: Convert the hex bytes into a long string of bits: (example only here.) 09 00 00 20 00001001 00000000 00000000 00100000 00001001000000000000000000100000 Then start pulling out 6 bits at a time and compare with the ASCII table I made earlier until you've got less than 6 bits left. ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/ (Where A=0, B=1, C=2,..... +=62, /=63) 000010 010000 000000 000000 001000 00 >>>>>>>> C Q A A I ..... So after making 5 characters, there are 2 bits left, Red Alert needs this to be 6 bits, so you would need another 4 bits. As you know, each character means 6 bits, and the '=' character means take the last 2 bits off. So you would use this idea to pad 4 bits onto the end using 'A=' which means 0000 The final string therefore would be: CQAAIA= And remember that 2 bits could also be left behind, you would use 'A ' in this case. How To Decode The OverlayPack in HEX Form Well, it will produce a 16k binary, with 1 byte representing each cell Here is the format of the packed section bb cc 20 ..... Where ccbbaa is the length of the ... section The &h20 may have a special meaning, but I've no idea yet. There are two of these in each OverlayPack, with each representing 8k. After a VERY VERY VERY long time, I was able to work out how the .... part was coded, just by luck really. Use Format80 to decode this, using an 8K destination buffer in each case, then join both these together to get a 16k file. Look at Appendix A (the Format80 images) for more information on this algorithm. This 16k file produced by the algorithm then reads from left to right like this: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+-+ +FF+FF+FF+FF+FF+FF+FF+FF+FF+FF+FF+FF+FF+FF+FF+FF+FF+FF+FF+FF+FF+FF+FF+FF+ ...... +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+-+ +FF+FF+FF+FF+FF+FF+FF+FF+FF+FF+FF+FF+FF+FF+FF+FF+FF+FF+FF+ ... +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ ........ The top left cell would be offset 0, the one below 128, and the one below that 256, (the same as the cell number). Here is a table of what each Hex represents in the OverlayPacks: FF - Blank 00 - Sandbags (SBAG) 01 - Chain-link Fence (CYCL) 02 - Concrete Wall (BRIK) 03 - C&C Barbed Wire (FENC) 04 - Wooden Fence (WOOD) 05 - Ore (GOLD01) Most Dense 06 - Ore (GOLD02) The Ore/Gem tiles do not SEEM to be 07 - Ore (GOLD03) any different, but they must be, both 08 - Ore (GOLD04) Least Dense RA and the editor seem to make single 09 - Gems (GEM01) Most Dense cell gem/ore tiles look the same, and 0A - Gems (GEM02) they only look different in clumps. 0B - Gems (GEM03) 0C - Gems (GEM04) Least Dense 0D - Haystacks (V12) 0E - Haystack (V13) 0F - Wheat Field (V14) 10 - Fallow Field (V15) 11 - Corn Field (V16) 12 - Celery Field (V17) 13 - Potato Field (V18) 14 - Circular Thing (FPLS) 15 - Wood Crate (WCRATE) 16 - Silver Crate (SCRATE) 17 - RA Barbed Wire (BARB) 18 - RA Sandbags (exactly same as C&C ones) (SBAG) 19 .. - I've only tested 19h and 1Ah, but I assume the rest also crash RA FE I've noticed that the Water Crate (WWCRATE) is missing, I've tried 19h and 1Ah onto Water tiles, but it still crashes. Also the concrete floor tile (CONC) is not there either, although if you look at my scenario creation guide, you can put both these on using the OVERLAY section. Recompressing Overlay Data To An Overlaypack How To Get The 'Compressed' Binary To A Map File It is nearly exactly the same as the overlaypacks, with 6 .... parts though instead of the two mentioned above. The map should be 48k when expanded (i.e 3 bytes per cell, 128x128x3) Using Format80 again for each ... section, an 8k destination buffer, and again, splice all these 6 together to make 48k. Here is a simple BASIC-like representation of how it is done: DIM MAP(0 to 127,0 to 127,1 to 3) as byte FOR Y=0 to 127 FOR X=0 to 127 GET 1 BYTE, PUT IT INTO MAP(X,Y,1) GET 1 BYTE, PUT IT INTO MAP(X,Y,2) NEXT NEXT FOR Y=0 to 127 FOR X=0 to 127 GET 1 BYTE, PUT IT INTO MAP(X,Y,3) NEXT NEXT It is quite strange, but It's Westwood's solution to use more than 256 tiles, which was the limit in C&C. Well the hex from the new 48k file is 3 bytes per cell, with them meaning the following : [ xx xx ] [ xx ] Tile I.D. Part Of That Tile To Show In That Cell Here are some of them, I'll probably get round to doing a full list sometime, but I havent checked the old C&C resources for this *yet*. Remember the Tile ID is a word, so I've switched it round (as you should), just in case you think it looks wrong :) TILE ID NO. OF PARTS ------- ------------ FFFF ? - Blank Tile 0001 ? - Water Recompressing Map Data back into a MapPack Appendix A : Format80/40/20 Images (thanks to Vladan Bato) I will call the three image formats Format80, Format40 and Format20. The Format80 images are compressed with a compression method I'll explain later. The Format40 images must be xor-ed with a Format80 image. That's what the RefOffs and RefForm fields are used for. They tell which Format80 image they are based upon. The Format40 will be explained in detail later. The Format20 images use the same format as the Format40, the difference is that they are xor-ed with the image that precedes them in the file. That can be either in Format20 or in Format40. The RefOffs field contains the number of the first Format40 image in the chain, and the RefForm field is always 4800h. Here's an example : 0) Off0 8000h 0000h 0000h 1) Off1 8000h 0000h 0000h 2) Off2 4000h Off1 8000h 3) Off3 8000h 0000h 0000h 4) Off4 4000h Off1 8000h 5) Off5 2000h 0400h 4800h 6) Off6 2000h 0400h 4800h 7) Off7 4000h Off3 8000h For example to draw image 7, you have to draw the image 3 first (whose offset and format are given) and then xor image 7 over it. To draw image 6, you have to xor it over the previous image, i.e. 5, which is format20 again, that means that it has to be xor-ed over image 4, which is in format40, i.e. it must be xor-ed over the image in format80 it has a reference to. In this case it's image 1. Thus the chain is 1,4,5,6. This is one way to see it, the other could be : Image 6 is in Format20, the RefOffs field contains the number of the first Format40 image in the chain, in this case image 4. To draw Image 4, the Image 1 has to be drawn first, next is image 4, and then all the images from the 4th to the 6th have to be xor-ed over the previous. I made some experiments and found out that you don't have to use the Format40 and Format20 images. I tried converting all of them into Format80 and it worked. Also, when changing graphics, note that all the unit and structure graphics should be drawn using the GDI colors, which will be automatically converted for the other sides. The palette you should use is one of those found in DESERT.MIX, WINTER.MIX and TEMPERAT.MIX. The GDI colors are colors 0B0h-0BFh. The other colors won't be converted and will remain the same for all the sides (be sure to use only the colors that are the same all three palettes). The above applies only to the graphics that appear in all three theaters (the .SHP file found in CONQUER.MIX). The graphics for the structures and overlays that appear in a single theater (found inside the theater specific MIX) can use the palette entries that are unique for that theater (and will be shown with garbled colors in the others). Also a special color is used for shadows. It's color 04h. In the palettes it's bright green, but C&C puts a shadow instead of it. I don't know how the shadows are calculated however. You should've noticed that the array has NumImages+2 elements when only NumImages elements are needed. The last one contains zeros, and the one before that points to the end of the file. These two can be used to identify the file as a .SHP. Here's the description of the compression formats : Format80 and Format40. ---------- Format80 ---------- There are several different commands, with different sizes : form 1 to 5 bytes. The positions mentioned below always refer to the destination buffer (i.e. the uncompressed image). The relative positions are relative to the current position in the destination buffer, which is one byte beyond the last written byte. I will give some sample code at the end. (1) 1 byte +---+---+---+---+---+---+---+---+ | 1 | 0 | | | | | | | +---+---+---+---+---+---+---+---+ \_______________________/ | Count This one means : copy next Count bytes as is from Source to Dest. (2) 2 bytes +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+ | 0 | | | | | | | | | | | | | | | | | +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+ \___________/\__________________________________________________/ | | Count-3 Relative Pos. This means copy Count bytes from Dest at Current Pos.-Rel. Pos. to Current position. Note that you have to add 3 to the number you find in the bits 4-6 of the first byte to obtain the Count. Note that if the Rel. Pos. is 1, that means repeat Count times the previous byte. (3) 3 bytes +---+---+---+---+---+---+---+---+ +---------------+---------------+ | 1 | 1 | | | | | | | | | | +---+---+---+---+---+---+---+---+ +---------------+---------------+ \_______________________/ Pos | Count-3 Copy Count bytes from Pos, where Pos is absolute from the start of the destination buffer. (Pos is a word, that means that the images can't be larger than 64K) (4) 4 bytes +---+---+---+---+---+---+---+---+ +-------+-------+ +-------+ | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 0 | | | | | | +---+---+---+---+---+---+---+---+ +-------+-------+ +-------+ Count Color Write Color Count times. (Count is a word, color is a byte) (5) 5 bytes +---+---+---+---+---+---+---+---+ +-------+-------+ +-------+-------+ | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | | | | | | | +---+---+---+---+---+---+---+---+ +-------+-------+ +-------+-------+ Count Pos Copy Count bytes from Dest. starting at Pos. Pos is absolute from the start of the Destination buffer. Both Count and Pos are words. These are all the commands I found out. Maybe there are other ones, but I haven't seen them yet. All the images end with a 80h command. To make things more clearer here's a piece of code that will uncompress the image. DP = destination pointer SP = source pointer Source and Dest are the two buffers SP:=0; DP:=0; repeat Com:=SourceSP; inc(SP); b7:=Com shr 7; {b7 is bit 7 of Com} case b7 of 0 : begin {copy command (2)} {Count is bits 4-6 + 3} Count:=(Com and $7F) shr 4 + 3; {Position is bits 0-3, with bits 0-7 of next byte} Posit:=(Com and $0F) shl 8+SourceSP; Inc(SP); {Starting pos=Cur pos. - calculated value} Posit:=DP-Posit; for i:=Posit to Posit+Count-1 do begin DestDP:=Desti; Inc(DP); end; end; 1 : begin {Check bit 6 of Com} b6:=(Com and $40) shr 6; case b6 of 0 : begin {Copy as is command (1)} Count:=Com and $3F; {mask 2 topmost bits} if Count=0 then break; {EOF marker} for i:=1 to Count do begin DestDP:=SourceSP; Inc(DP); Inc(SP); end; end; 1 : begin {large copy, very large copy and fill commands} {Count = (bits 0-5 of Com) +3} {if Com=FEh then fill, if Com=FFh then very large copy} Count:=Com and $3F; if Count<$3E then {large copy (3)} begin Inc(Count,3); {Next word = pos. from start of image} Posit:=Word(SourceSP); Inc(SP,2); for i:=Posit to Posit+Count-1 do begin DestDP:=Desti; Inc(DP); end; end else if Count=$3F then {very large copy (5)} begin {next 2 words are Count and Pos} Count:=Word(SourceSP); Posit:=Word(SourceSP+2); Inc(SP,4); for i:=Posit to Posit+Count-1 do begin DestDP:=Desti; Inc(DP); end; end else begin {Count=$3E, fill (4)} {Next word is count, the byte after is color} Count:=Word(SourceSP); Inc(SP,2); b:=SourceSP; Inc(SP); for i:=0 to Count-1 do begin DestDP:=b; inc(DP); end; end; end; end; end; end; until false; Note that you won't be able to compile this code, because the typecasting won't work. (But I'm sure you'll be able to fix it). ---------- Format40 ---------- As I said before the images in Format40 must be xor-ed over a previous image, or against a black screen (as in the .WSA format). It is used when there are only minor changes between an image and a following one. Here I'll assume that the old image is in Dest, and that the Dest pointer is set to the beginning of that buffer. As for the Format80, there are many commands : (1) 1 byte byte +---+---+---+---+---+---+---+---+ | 1 | | | | | | | | +---+---+---+---+---+---+---+---+ \___________________________/ | Count Skip count bytes in Dest (move the pointer forward). (2) 3 bytes byte word +---+---+---+---+---+---+---+---+ +---+-----+-------+ | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | | 0 | ... | | +---+---+---+---+---+---+---+---+ +---+-----+-------+ \_____________/ | Count Skip count bytes. (3) 3 bytes byte word +---+---+---+---+---+---+---+---+ +---+---+-----+-------+ | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | | 1 | 0 | ... | | +---+---+---+---+---+---+---+---+ +---+---+-----+-------+ \_____________/ | Count Xor next count bytes. That means xor count bytes from Source with bytes in Dest. (4) 4 bytes byte word byte +---+---+---+---+---+---+---+---+ +---+---+-----+-------+ +-------+ | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | | 1 | 1 | ... | | | | +---+---+---+---+---+---+---+---+ +---+---+-----+-------+ +-------+ \_____________/ value | Count Xor next count bytes in Dest with value. 5) 1 byte byte +---+---+---+---+---+---+---+---+ | 0 | | | | | | | | +---+---+---+---+---+---+---+---+ \___________________________/ | Count Xor next count bytes from source with dest. 6) 3 bytes byte byte byte +---+---+---+---+---+---+---+---+ +-------+ +-------+ | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | | | | | +---+---+---+---+---+---+---+---+ +-------+ +-------+ Count Value Xor next count bytes with value. All images end with a 80h 00h 00h command. I think these are all the commands, but there might be some other. If you find anything new, please e-mail me. As before here's some code : DP = destination pointer SP = source pointer Source is buffer containing the Format40 data Dest is the buffer containing the image over which the second has to be xor-ed SP:=0; DP:=0; repeat Com:=SourceSP; Inc(SP); if (Com and $80)<>0 then {if bit 7 set} begin if Com<>$80 then {small skip command (1)} begin Count:=Com and $7F; Inc(DP,Count); end else {Big commands} begin Count:=Word(SourceSP); if Count=0 then break; Inc(SP,2); Tc:=(Count and $C000) shr 14; {Tc=two topmost bits of count} case Tc of 0,1 : begin {Big skip (2)} Inc(DP,Count); end; 2 : begin {big xor (3)} Count:=Count and $3FFF; for i:=1 to Count do begin DestDP:=DestDP xor SourceSP; Inc(DP); Inc(SP); end; end; 3 : begin {big repeated xor (4)} Count:=Count and $3FFF; b:=SourceSP; Inc(SP); for i:=1 to Count do begin DestDP:=DestDP xor b; Inc(DP); end; end; end; end; end else {xor command} begin Count:=Com; if Count=0 then begin {repeated xor (6)} Count:=SourceSP; Inc(SP); b:=SourceSP; Inc(SP); for i:=1 to Count do begin DestDP:=DestDP xor b; Inc(DP); end; end else {copy xor (5)} for i:=1 to Count do begin DestDP:=DestDP xor SourceSP; Inc(DP); Inc(SP); end; end; until false; Appendix B : CPS Files The .CPS files contain 320x200x256 images. The images are compressed with the Format80 compression method. They may or may not contain a palette. The header has the following structure : Header : record Size : word; {File size - 2} Unknown : word; {Always 0004h} ImSize : word; {Size of uncompressed image (always 0FA00h)} Palette : longint; {Is there a palette ?} end; If Palette is 03000000h then there's a palette after the header, otherwise the image follows. CPS file without palette can be found in the SETUP.MIX file, and they all use the Palette that can be found inside the same .MIX. The image that follows the palette (or the Header) is in Format80 which is explained above. My Note : The CPS files contain all the full screen Red Alert Images, where PCX files are used for the 640x400 images used in the Windows '95 version. Thanks to: Westwood for making the great game Everyone who contributed to the "Scenario Creation Guide" Mike Cocca for help on the MapPacks. Moritz Mertinkat for writing RA-MiXer 3.0, I found this very handy when looking for the offsets, as I myself only could find the SHP files reliably :), and for the RMT/PCX info! Vladan Bato for the C&C Format80/40/20 images and for the great work on the old C&C MIX files. Andrew Griffin for the correction of the RMT files. Anyone who thinks they deserve it. Also, email me if you see anything that is wrong, or missing, or should be included, I'll give you credit for that particular part of course :) You'll find the latest version of this text here: http://www.geocities.com/TimesSquare/Arcade/5553 ©Gavin Pugh 1997 rascenedit@geocities.com Category:Red Alert 1